The concept of the game is Airlock is an arena fighting game with the goal of your player knocking every other player in the game off the map and being the last standing in a free-for-all-like game mode. Use your fists and items scattered around the arena to attack the other players to knock them back aiming for certain wall panels which could break causing Airlock breaches dragging the players nearby out eliminating them. After a certain amount of time if there is still more than one player standing the winner is decided by a race and whoever first presses the button at the end.
The goal of this group project was to create a medium fidelity game within 7-8 weeks from the ideas proposed by the client in a group of 5-6 to help them evaluate their ideas to see what works or needs to be changed to create a fun game that people want to play. At the start of the project the client helped significantly by having written down their ideas and breaking them down into segments of work that would need to be completed to achieve the desired result however also allowing us creative control of additional features and ideas the team had including deciding the art direction it would go, with the group running our potential ideas by them to see if it was something they wanted and checking that the team was working in the right direction at major milestones of development.
The software used by the group for this project was include Blender, Unity, Substance-Painter, Visual-Studio Code, discord for communication and GitHub to all work on the same Unity project together allowing us to all be on the same basis for the project and help compile our work together in one source.
The research for this project was mostly focused on the art design aspects as the client helpfully laid out what they wanted coding and mechanics for the game. In contrast, we had mostly free reign on the art style using the client's inspiration with games such as smash bros and gang-beasts as our pivot eventually settling for a more stylised art direction to keep the game looking casual and fun, appealing to a larger audience at the end we settled on an art style being a mix between a similar game called gang-beasts for its simple and unique character designs and a unrelated game called risk of rain 2 for its unique and stunning stylised graphics.
The group roles were assigned based on preference but mostly on where the team member's skills lay and areas that needed more work compared to others. This ended with 2 people being assigned to work on code including me and 2 others being assigned to work on the design aspects being split into 3D, 2D and UI respectively with our last member assigned to work on bits of both to fill in gaps where needed. One extra member was added to the group around week 5 and assigned UI design as that was the area worked on the least during that time and needed help to get caught up with the rest of the project. Overall, the team lead role went to Ethan during the first week with him helping everyone stay on task and ensuring work was done.
The tasks assigned to me at the start of the project were the Smash-bros-like volatility system to allow the player to knock back the other player, the tiebreaker race at the end of the round if there isn't one person standing after the timer is up to help decide the winner and also the win-lose conditions for the game and detecting if anyone has died and who the winner is. Then further down the development schedule I got assigned to do the entire fighting system and object pickups with me tweaking some other teammate's scripts to help integrate and improve efficiency. Throughout the project, I also worked on some small item models here and there in Blender to help out on the 3D design side of the project.
Some simple 3D models I made for the game as occasional obstacles that can be thrown into the players and or background filler using mostly simple techniques like subdivision modifiers and messing with vertices in edit mode but also some more advanced techniques like making the lattice on the AC unit. I helped create some extra props for the game as the client liked our idea of being able to use the surrounding area and items and weapons during the fight which required us as a team to make more items for variety to keep the game and background interesting for the player.
Some of the smaller scripts included those for the race and game manager, durability for items, the pickup script, and the rebound script that controls what the players can bounce off of.
The race manager script simply puts an observer on the game manager which listens out for the game manager to call out "racestart" which when heard by this script triggers it to find all of the objects in the current scene with the tags Players, Floor, and Race and then depending on those tags executes a different function teleporting the players to their designated start area, removing the floor to allow the players to drop, and toggling on the mesh of everything tagged race to make it appear.
The game manager works by first identifying both players by what we selected them as in the inspecter in unity and adds two listeners to their Player script which has code where on their perminate death or when touching the specified button it triggers the event of death or win and shouts it out allerting the game manager to what has happened and to which player allowing for the specified code to exercute depending on what it is like if player 2 dies it activaites on player2 death which if player 1 is also dead ends in a draw but if not it states that player 1 wins. This code also allowing for events to be invoked to trigger other actions such as a win screen or scene change.
With the pickup script, it works universally as long as the other object is tagged with "Item" allowing the player to pick it up by checking it when entering the trigger of the Item and if it has picked up another Item it can't pick up another with the use of a bool of "hasItem". The code when picking up an item works by finding the object's rigid body and capsule-collider that we are currently touching and stopping its ability to move and disabling the collide to stop it from interacting with the player's movement whilst also making it a child of the player model so it moves around with the player while dropping it reverts all that back. It also interacts with the durability script on that item and connects to the attacking script to detect every attack with the item to take away durability
The Player script managers the volatility system for the players, as well as the death and respawn conditions by first getting the rigidbody of the player the script, is attached to and setting the knockback multiplier to one at the start of the original version of the player script had a lives system allowing the players to have 3 lives at the start of each game and they would lose lives by falling off the platform like in smash-bros however when presenting this iteration to our client they envisioned it to work in another way with the player being able to die indefinitely however every time they die they respawn in with a higher starting knockback multiplier instead allowing for longer but more hectic and fun matches as well as a change where the players can still permanently die however only in certain areas of the map which are harder to knock the enemy player into allowing a level of skill to the game. Hearing the changes they wanted I started to get to work on it by first removing the lives feature and instead replacing it with each death adding a specific amount of extra knockback depending on the amount of death giving it a snowballing effect but being able to cap out at a decided amount which currently is 25 to allow the game to still be playable, also with the permanent death there are invisible triggers around the map called "deathboxes" that when the player enters kills them completely. there is also slightly different coding for a separate attack called an uphit which is performed when jumping and then attacking resulting in the enemy being launched further up but not as far horizontally compared to the basic attack our client also wanted a larger variety of options when attacking.
The attacking script originally all ran off multiple if statements in the update function but thinking about if this proceeds further with the client and anyone else working on it after me having difficulty I changed it into a state machine as it's industry standard and easier to make changes to even if you don't know the script well. The attacking script manages all the ways of attacking including basic, weapon, blocking as well as "uphit" where it constantly checks what keys are pressed in groups of two and if they match a pre written key list triggering the exercution of the uphit code whilst if it doesn't match the list after 2 keys pressed or after a certain amount of time it resets. Whilst everything else depends on the state, changing the basic attacks knockback-increase and the attack range with blocking stopping damage altogether for as long as you hold down the right mouse up to 5 seconds going into a cooldown until you can block again. This variety of attacks and other options was derived from the client wanting a modern in-depth fighting system which can be easily built on.
Whilst most of the teamwork was in preproduction and deciding what everyone was going to work on individually and later compile together in one project there were still some instances of joint effort like with the player movement script whilst Ethan did most of the work there was still input from others with myself updating the ground check to a raycast and others adding ideas to what can be improved on like movement tools like rockets boots and the grappling hook.
Attacking and Tiebraker race
Pickup, movement, and wallbreak + repair
Overall I believe the project went well with the group managing to compile a decent snippet of the possible game for the client to play test in their own time to see what might need to be changed and what works well and can be developed more down the line. Working on this project significantly improved my hard skills and soft skills with leaps in my coding ability being more knowledgeable about aspects that previously I didn't have much experience with, like learning multiple uses of lists systems in unity code and how to properly implement a state-machine. Some of the soft skills developed are critical to better performance in the future such as being able to effectively communicate with a client and listen to the ideas and suggestions they have while taking on criticisms on the work you have done to be able to improve as desired, as well as learning the importance of a good team lead and teammates in this case Ethan helping push everyone along so more work was done and the group managing to stick mostly in the timelines set and the help that having decent teammates are to assist you if you're stuck on something and can't figure it out on your own even with just providing a new prospective to the issue. I found out that while in a team I'm effective at filling in multiple different roles when there is a need, helping develop my skills in multiple areas and allowing me to be a more diverse teamplayer.
Things that could be changed next time or if this project was undertaken again would be mainly to reach out and communicate with the client quicker as we took up till the first milestone to update our client on the progress where we could have streamlined the preproduction if we also had the clients input as to help narrow down ideas and get to what they want quicker. Another thing that would be changed is the frequency of communicating with the client instead of every milestone it could be every week to keep them updated on how it's going and help catch us developing in a different direction than they imagined like with my original attacking script where instead the client wanted it slightly different than how I imagined.
In conclusion, the steps we took during the project while adequate for our current level of work could have still been better with further research at the beginning as whilst the client helpfully laid out the game mechanics for us and the inspirations for the game it was still up to us as a group to figure out the art direction and style of the game and any additional mechanics for the game with the group settling on an art style to similar to games like risk of rain 2 and gang-beast however we never went into detail on how we would merge those styles leading to bottlenecks further in development and also leading to discrepancies in our planning with having to fit in additional mechanics we wanted to include into the already tight schedule and weighing what we could focus less on to work on what is more important as well as having to figure out more on the stylisation slowing down the overall progress that could have been made. However, overall the role assignment was quite spot on leaning towards individual strengths to maximise everyone's effectiveness and overall ability to work on the game.